The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Computer program applications in an enterprise networked environment often interact with other applications and users on behalf of a user or an application. As a part of such interactions, the applications may need to maintain data about sessions of applications and users. Session data may be used by applications to store any state information that is relevant to the application or its interaction with a user or system. For example, an application may first authenticate a user before it allows other requests from the same user. If a user has not authenticated before making a request, such request may be denied or may fail. Information about whether a particular user is authenticated may be stored in session data. Session data also may be used to provide any user or application personalization, context-aware responses, or configuration.
A computer network normally comprises end station devices that are interconnected using network infrastructure devices. Examples of end station devices include server computers, personal computers, and printers. Examples of network infrastructure devices, also termed networking devices, are routers, switches, bridges and hubs. Typically, session information is managed and stored only by application endpoints or hosts, such as server computers.
If application needs to offload any function to another host or network element, then the application normally needs to provide necessary context information so that the offloaded function can be performed properly. Session data can provide the context information. For example, if an application offloads security operations (e.g., authentication and authorization), monitoring functions, or other operations to a network element, then the application also needs to provide information about the session or context in which such a function is to be performed.
In past approaches, applications have created and maintained session and context information and providing the information to the host where the information is used. For example, web servers create and store cookies on client computers, and browsers at the client computers use such cookies to keep the context of user operations in an HTTP session. This example involves information that is application specific and does not involve an offloaded function.
In past approaches, session or application context has been created in load balancing application requests based on the target destination and resource URI. However, such load balancing context information is created using only the protocol header fields of a client request. Certain application servers such as the Tomcat server perform session management based on the HTTP protocol only. Further, some protocols do not include widely used mechanisms for storing information in protocol headers of messages, and any useful context information is found only in the content payloads of the messages.